Systems and methods for providing categorization based authorization of digital assets

ABSTRACT

Systems and methods for managing digital assets in a distributed computing environment are described. Meta-data for the digital assets is stored separately from the digital assets. Meta-data for some of the digital assets is copied and stored at a central location. Meta-data for the digital assets is generated by clients of the system.

FIELD OF THE INVENTION

The invention relates to managing digital assets in a distributedcomputing environment. More specifically, the invention relatesproviding categorization based authorization of digital assets.

BACKGROUND OF THE INVENTION

Centralized document management and other centralized applications canease digital asset management tasks. However, these tools are expensive,difficult to install and configure, and require end-users to change themanner in the way they work and interact with each other. Thesesolutions are also very dependent upon the end-users to self-enforcecorporate governance policies with respect to the digital assets thatthey create.

The centralized file control mechanism used by these present solutionstypically requires end-users to use a burdensome check-in/check-outprocess to obtain files. However, many end-users prefer not to give upcontrol of their digital assets, are unwilling to sacrifice the abilityto use their laptops when they are detached from the corporate network,and resist the workflow requirements of centralized systems. This leavesopen the potential for many files located on file servers, laptops,desktops, personal digital assistants (PDAs), and other computingdevices to remain outside the controls of the digital asset managementsystem.

Additional drawbacks of current centralized document management toolsinclude: the inability to categorize all digital assets on a storagedevice; the poor quality of existing categorization techniques when usedwithin a structured context; the inability to provide effectiveautomated control over categorization of digital assets as they arecreated and changed; the inability to request categorization informationfrom the end-user; the inability to selectively record categorizationinformation based on the conceptual value of the assets; and the lack ofcategory maintenance as assets are copied, moved, renamed, deleted andrestored.

There is, therefore, a conflict between the benefits of centralized filemanagement and end user behavior; a tension which limits the amount ofinformation that will be captured by a centralized document managementsystem.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order toprovide a basic understanding of some aspects of the invention. Thissummary is not an extensive overview of the invention. It is notintended to identify key or critical elements of the invention or todelineate the scope of the invention. Its sole purpose is to presentsome concepts of the invention in a simplified form as a prelude to themore detailed description presented below.

As a general introduction, the invention includes a computer softwaresystem for gathering and recording categorization data when a digitalasset (e.g., file, voicemail, instant message log, email, and the like)or a digital asset container (e.g., folder, directory, disk drive,removable storage medium, and the like) is created. The system executesin a pre-emptive multi-tasking environment. In various embodiments, thesoftware system provides the following features: the ability tocategorize existing digital assets in a file system; categorizingdigital assets upon creation; a structured and adaptable set of terms(i.e., a taxonomy) for categorization; rule-based categorization ofdigital assets, minimal change or interruption to the end-user while thesoftware system is in use; the ability to gather meta-data about thedigital assets from the end-user; categorization meta-data that isindependent of the stored digital asset and structured for simpleretrieval of the digital asset; segregation of categorization meta-data(e.g., storing only the meta-data for a digital asset is indicated ofvalue); maintaining the meta-data over time; and propagating themeta-data with the digital asset when the digital asset is transmitted,printed, moved, or copied.

In one aspect, the present invention allows the end-user to leave adigital asset in the location it is most productive to the end-userrather than moving everything into a centralized repository. In today'sdistributed and mobile corporate world, it is important that informationreside locally with the end-user to enhance productivity while remainingunder control of the corporation. To this end, the present inventionprovides a means to categorize digital assets at the point of creationwith little or no work on the end-user's behalf. The location of digitalassets is tracked without requiring the digital asset by stored at acentral location.

Once digital assets are categorized, the present invention allows apolicy application to the digital assets. One benefit provided by thisfeature is that corporations can apply policies to digital assetsaccording to a centralized policy. For example, a corporation decidesupon a behavior such as privacy for specific human resource digitalassets. That policy is then applied to all digital assets of that type,regardless of the form of the digital assets (e.g., files, email,instant message (IM) logs, etc) that are tagged as human resourcesdigital assets.

In order to provide the necessary level of control and management,operations performed on the digital assets can be audited. For example,using the categorization the end-user or administrator can set the levelof audit to be performed. In one embodiment, a low level of audit wouldsimply keep track of copies and relationships while a high level ofaudit would keep track of every operation that took place on the digitalasset and for the length of time required to perform the operation.

Other features provided by the present invention include, but are notlimited to retention/deletion of digital assets, automatic creation ofcopies of digital assets, prevention of operations on digital assets,expiration of archived copies of digital assets, storing meta-dataseparate from the digital asset, prevention of restoration of expireddigital assets, searching the digital assets using virtual foldershaving labels based on the meta-data, copy tracking of digital assets,combining meta-data tags, propagating the meta-data tags with thedigital assets, providing an adaptive taxonomy used to create meta-datafor the digital assets.

Retention/Deletion: Each type of digital asset has controls on theminimum length of time that the digital asset is stored and possibly themaximum length the digital asset can be stored. This translates tostoring digital assets for a given period of time and then eitherarchiving the digital asset or destroying the digital asset. In certainembodiments, the present invention provides this feature.

Automatic Copy: There are a number of reasons to make automatic copiesof digital assets. For example, the end-user or administrator could seta policy to make a copy of financial digital assets. Another examplewould be to make a copy of digital assets from a local storage device toa centralized storage device so the digital assets can be archived(i.e., backed-up). In certain embodiments, the present inventionprovides such functionality.

Prevention of Operations: In various embodiments, the present inventionapplies a policy to block certain operations from being performed on adigital asset. For example, specific digital asset can be prevented frombeing transmitted outside of the company. Another example of a policy isto prevent specific digital assets from being copied to specific devicessuch as removable media, e.g., USB devices. Policies can also be appliedbased on the role of the end-user to provide role based access controlto certain digital assets.

Expiration of Archived Copies: In certain embodiments, specificexpiration policies are applied to digital assets. When copied to thestorage medium for archiving, these policies are copied along with thedigital assets. Should an attempt to restore the copies from the storagemedium, the policies applied to the copies prevent their restoration. Inother embodiments, an encryption key that was used to encrypt the copiesprior to storage on the medium is destroyed after an assigned expirationdate.

Additional features and aspects of the invention are described ingreater detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

The advantages of this invention, described above, and furtheradvantages, may be better understood by referring to the followingdescription in conjunction with the accompanying drawings, in which likenumerals indicate like structural elements and features in variousfigures. The drawings are not necessarily to scale, emphasis insteadbeing placed upon illustrating the principles of the invention.

FIG. 1 shows an embodiment of a distributed computing environment (DCE).

FIG. 2 shows an embodiment of a client of the DCE of FIG. 1 constructedaccording to principles of the invention.

FIG. 3 shows an embodiment of a server of the DCE of FIG. 1 constructedaccording to principles of the invention.

FIG. 4 shows an embodiment of an adaptive taxonomy that incorporatesprinciples of the invention.

FIG. 5 shows a flow chart of an embodiment of a method of generatingmeta-data for a digital asset using the client software of FIG. 2 thatis operating according to principles of the invention.

FIG. 6 shows an embodiment of a method of providing meta-data using agraphical user interface according to principles of the invention.

FIG. 7 shows an embodiment of a method of generating a digitalidentifier for a digital asset according to principles of the invention.

FIG. 8 shows an embodiment of a method of tracking copies of a digitalasset according to principles of the present invention.

FIG. 9 shows an embodiment of a method of locating a digital asset inthe distributed computing environment according to principles of theinvention.

FIG. 10 shows an embodiment of a graphical display of a locate resultconstructed according to principles of the invention.

FIG. 11 shows an embodiment of a method of expiring a digital assetaccording to principles of the invention.

FIG. 12 shows an embodiment of a method of preventing the restoration ofan expired digital asset according to an embodiment of the invention.

FIG. 13 shows an embodiment of a method of performing categorizationbased access to a digital asset.

FIG. 14 shows an embodiment of a method of propagating the meta-datawith a digital asset.

FIG. 15 shows an embodiment of a method of creating an alias to a tag ofthe adaptive taxonomy of FIG. 4.

FIG. 16 shows an embodiment of a method of unionizing differentmeta-data sets for the same digital asset in accordance with principlesof the invention.

FIG. 17 shows an embodiment of a method of identifying digital assets inthe DCE of FIG. 1.

DETAILED DESCRIPTION

The present invention provides systems and methods for managing digitalassets in a distributed computing environment (DCE). The inventionrelates generally to the collection, recording and maintenance ofmeta-data that identifies and categorizes stored digital assets forlater location, retrieval and application of business controls. The termmeta-data and asset identification tag are used synonymously throughoutthe specification to refer to the information that is created and usedby the present invention to identify and categorize digital assets.Although some of the meta-data created by the present inventioncorresponds to known meta-data of a file system (e.g., the i-nodeassociated with a file by the Unix operating system or a Master FileTable Record used by the WINDOWS operating system, manufactured byMicrosoft Corporation of Redmond, Wash.) the meta-data of the presentinvention supplements and extends the known file system meta-data.

With reference to FIG. 1, a distributed computing environment (alsoreferred to as a client/server system) 100 in which principles of thepresent invention can be practiced includes one or more clients 110,110′, 110″ (hereinafter each client or plurality of clients is generallyreferred to as 110) in communication with one or more servers 150, 150′(hereinafter each server or plurality of servers is generally referredto as 150) via communications network 140 through communications links120. The communications network 140 can be a local-area network (LAN), amedium-area network (MAN), or a wide area network (WAN) such as theInternet or the World Wide Web. The communication links 120 can be avariety of connections including standard telephone lines, LAN or WANlinks (e.g., T1, T3, 56 kb, X.25), broadband connections (e.g., ISDN,Frame Relay, ATM), and wireless connections (e.g., IEEE 802.11). Theclients 110 and servers 150 communicate through the network 140 using avariety of communication protocols (e.g., TCP/IP, IPX, SPX, NetBIOS,NetBEUI, and direct asynchronous protocols).

Additionally, the clients 110 can communicate with other clients 210,210′, 210″ (hereinafter each other client or plurality of other clientsis generally referred to as 210), which can be connected to a secondnetwork 240, through a communication link 180 that connects network 140to the second network 240. The protocols used to communicate throughcommunications link 180 can include any variety of protocols used forlong haul or short transmission. For example, TCP/IP, IPX, SPX, NetBIOS,NetBEUI, SONET and SDH protocols.

The client 110 can be any personal computer, Windows-based terminal,Network Computer, wireless device, information appliance, RISC Power PC,X-device, workstation, minicomputer, main frame computer, cellulartelephone or other computing device that provides sufficient facultiesto execute client software and an operating system. Client software ofthe invention facilitates the creation of meta-data that identifies,categorizes, and characterizes the digital assets generated and storedby the client. As used herein, digital asset refers to any digital filethat can be stored in a storage medium. Examples of digital assets caninclude, but are not limited to, files, emails, instant messages (IM),audio files, video files, profiles, drivers, programs, and otherelectronic embodiments of information.

The server 150 can be any type of computing device that is capable ofcommunication with the client 110. For example, the server 150 can be atraditional server computing device, a web server, an applicationserver, a DNS server, or other type of server. Additionally, the server150 can also be a client 110 (e.g., in an ad-hoc or peer-to-peer (P2P)network arrangement). One purpose of the server 150 is receiving,storing, and managing meta-data associated with the digital assets ofthe clients 110. The sever 150 can also provide a means to modify andupdate a taxonomy used to categorize and create meta-data for thedigital assets, request that the client perform operations on its storeddigital assets, and generate reports on the state of the storedmeta-data. One example of a server 150 that can be used with theinvention is a DELL server classes computer having 1 gigabyte of RAM,dual central processing units, a 250 gigabyte hard drive, and an networkinterface card. It should be understood that more than one server 150can be used with the present invention. In such a configuration,functionality can be distributed across the servers 150 or each server150 can provide a full suite of functionality.

FIG. 2 depicts a conceptual block diagram of a client 110 of thedistributed computing environment 100. Each client 110 typicallyincludes a processor 200, volatile memory 204, an operating system 208,client software 212, a persistent storage memory 216 (e.g., hard driveor external hard drive), a network interface 220 (e.g., a networkinterface card), a keyboard 224 or virtualized keyboard in the case of aPDA, at least one input device 228 (e.g., a mouse, trackball, spaceball, light pen and tablet, touch screen, stylus, and any other inputdevice), and a display 232. The operating system 116 can include,without limitation, WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS NT3.51, WINDOWS NT 4.0, WINDOWS 2000, WINDOWS XP, WINDOWS VISTA, WINDOWSCE, MAC/OS, Java, PALM OS, SYMBIAN OS, LINSPIRE, LINUX, SMARTPHONE OS,and the various forms of UNIX.

The client software 212 is in communication with various components ofthe client 110 to provide features of the invention. In one embodiment,the client software 212 includes an agent 250, one or more filterdrivers 254, and one or more plug-in modules 258. It should beunderstood that the client software 212 can include some or all of thecomponents shown and described. As a general overview, the clientsoftware 212 provides a means to create, edit, maintain, update, revise,modify, and produce meta-data that provides categorization andidentification of digital assets. The meta-data is associated with someor all of the digital assets created or stored on the client 110 and isused to provide tracking, locating, searching, and other features andaspects of the invention.

The agent 250 operates in the “user space” of the operating system 208as do a various plug-in (also referred to as Add-in) modules 258. Theagent 250 and plug-ins 258 are in communication with the various filterdrivers 254, which operate in the “system space” of the operatingsystem. Although shown in user space, it should be understood that incertain embodiments, the agent 250 can operate in the system space aswell. The cooperation of the agent 250, the filter drivers 254, and theplug-in modules 258 provide the end-user of the client 110 with thefeatures and operational characteristic of the invention. These featurescan be invisible to the end-user (e.g., automatic categorization ofdigital assets) or require end-user input through a graphical userinterface (GUI) (e.g., end-user categorization). For example, when arequest to create a folder is executed, the filter driver 254 interceptsthe command. The filter driver 254 communicates with the agent 250. Inresponse, the agent 250 displays a graphical dialog and asks theend-user for meta-data information (e.g., categorization information).In one embodiment, the client software 212 also interacts with a filesystem filter driver 258 that is provided as part of the operatingsystem 208. In another embodiment, the client software 212 replaces thefile system filter driver 258 provided by the operating system 208.

During certain modes of operation, the client software 212 interceptsfile system commands and performs various functions of the invention inresponse thereto. For example, prior to adding a new digital asset tothe file system of the client 110 the client software 212 intercepts thefile system command to create the digital asset and requires theend-user to provide at least a portion of the meta-data (e.g.,categorization information) associated with the digital asset. After theclient software 212 applies the meta-data, the digital asset is added tothe file system of the client 110. Another feature the client softwareprovides is the generation of a digital identifier that is associatedwith digital asset as part of the meta-data. The categorizationinformation and digital identifier form, in one embodiment, themeta-data that is associated with the digital asset. Another exemplaryfeature provided by the client software 212 is to perform a search orlocate. The end-user of the client issues a search or locate command,the client software 212 intercepts this command and provides a“virtualized” view of the contents of the file system of the client 110.Each of these examples is explained below in more detail.

The associated meta-data for each digital asset may or may not beforwarded to the server 150 via network interface module 220 andcommunications link 120. Whether the meta-data for the digital asset istransmitted to the server for storage depends on the categorization andrules applied to the digital assets. This provides for granular controlof certain digital assets of interest.

With reference to FIG. 3, an embodiment of a server 150 for user in thedistributed computing environment 100 is described. The server 150includes a processor 300, a volatile memory 304, an operating system308, server software 312, persistent storage memory 316, a networkinterface 320, a keyboard 324, at least one input device 328 (e.g., amouse, trackball, space ball, bar code reader, scanner, light pen andtablet, stylus, and any other input device), and a display 332. Theserver operating system can include, but is a not limited to, WINDOWSXP, WINDOWS 2000 SERVER, WINDOWS 2000 ADVANCED SERVER, WINDOWS NTSERVER, WINDOWS NT SERVER ENTERPRISE EDITION, MACINTOSH OS X SERVER,LINUX, UNIX, SOLARIS, VMWARE, and the like.

A central repository 336 (e.g., a database) is in communication with theserver 150. Although shown as separate from the server 150, it should beunderstood that the central repository 336 can be integral with theserver 150 or located elsewhere within the distributed computingenvironment 100. The central repository 336 is configured to storemeta-data associated with certain digital assets. In one embodiment, thedigital assets and their associated meta-data are stored at the clients110 and a copy of the associated meta-data is stored at the centralrepository 336. This provides a “decentralized” digital asset managementsystem, which enables certain features and advantages of the invention.For example, by not storing the digital assets themselves at the centralrepository 336 the end-users are not required to check-out and check-inthe digital assets in order to perform operations on the digital assets.

Additionally, the communication link 120 that connects the client 110 tothe server 150 does not need to be maintained thereby tethering theclient 110 to the server 150. Said another way, the communication linkcan be established on an “as-needed” basis. This feature allows theend-user to work “off-line” with the digital assets of interest andupload changes to the meta-data when a connection to the centralrepository 336 is established. Additionally, changes to the meta-datafor a digital asset can be downloaded from central repository 336 when aconnection is established. Also, various policies associated with themeta-data of the digital assets can require performance of specifictasks when the client 110 connects to the server 150. it should beunderstood that when the client 110 connects to the server 150 thesetasks are executed.

In certain embodiments, the server software 312 provides a means toperform certain features of the invention. For example, the serversoftware 312 allows an administrator to create and modify an adaptivetaxonomy that is used to create categorization information for a digitalasset. Also, the server software 312 propagates different meta-data setsfor the same digital each to each client 110 having a copy of thedigital asset. The clients 110, in turn, perform a union of thedifferent meta-data sets. In other embodiments, the server software 312cooperates with the client software 212 to enable other features of theinvention. For example, an administrator can issue a command using theserver software 312 to copy certain digital assets to a central locationin an effort to produce documents required in litigation. An example ofa function that is performed by the client software 212, but can also beprovided by the server software 312 is the ability to perform a union ofmeta-data for a digital asset and propagate a selected characterizationfor that digital asset. Each of these features is described in moredetail below

With reference to FIG. 4, an exemplary adaptive taxonomy 400 of theinvention is described. As used herein, taxonomy refers to ahierarchical structure of tags used to provide a method of organizingdigital assets. Conceptually, a taxonomy can be thought of as a treestructure having a root node 410, a plurality branches 420 connectingleaf nodes 430. Each leaf node 430 can have further braches 420 thatconnect the leaf nodes 430 to sub-leaf nodes 440 and so on. As used withreference to the taxonomy 400, the terms node and tag are synonymously.

Each node 430 and sub-node 440 can be applied to a digital asset as atag that is part of the meta-data for the digital asset. The tag that isused to identify and categorize the digital asset. When used properly, ataxonomy 400 not only helps an organization organize digital assets butthe taxonomy also helps identify types of digital assets. Policies canalso be associated with each node 430 and sub-node 440 of the taxonomy400. Applying a node 430 or sub-node 440 as a tag of the taxonomy to adigital asset also associates the policy for that node to the digitalasset. Examples of policies can include, but are not limited to,restricting access to a digital asset based on the role and/or identityof the end-user of the client 110, restricting replication actions basedon the destination of the copy of the digital asset or the presentlocation of the digital asset, and when the digital asset is removedfrom the client 110.

Although a taxonomy 400 is a powerful organizational tool, a rigidtaxonomy restricts the flexibility of digital asset characterization. Tothat end, the invention provides a mechanism in which modifications tothe taxonomy 400 can be made be the end-users of the clients 110 on anindividual level without requiring modifications to the general taxonomy400. Also, if a change to the general taxonomy 400 is required, theinvention provides a mechanism for propagating the changes to thetaxonomy 400 to the clients 110.

To accomplish these features, the invention provides the functionalityto create an “alias” for a node 430 or sub-node 440 in the taxonomy. Asused herein, an alias refers to an alternate name for the same tag inthe taxonomy 400. For example, the term “CV” (Curriculum Vitae) is usedin many parts of the world to have the same meaning as “resume” is usedin the United States. In the taxonomy 400, a tag 440 is labeled “Resume”and has an alias 450 labeled “CV” associated with it. Essentially, thealias 450 points to the associated tag 440 and has the categorizationand policy information as the tag 440. As will be described in moredetail below, the alias 450 can be a local alias meaning that isavailable only to a specific client 110 or the alias can be a globalalias meaning that the alias is available to all clients.

The invention includes functionality implemented, in one embodiment, bythe server software 312 to promote an alias 450 to a tag 440. Thepromotion does not change how the alias 450 has been used previously.That is, digital assets that were tagged with the alias 450 are stillgoverned by the same categorization and policy information of the alias450. It should be understood that the transition from an alias to a tag440 allows for the modification of the policies associated with thealias 450. Further details of the adaptive taxonomy 400 are providedbelow.

With reference to FIG. 5, the method 500 for generating meta-data for adigital asset is shown and described. In one embodiment, a client 110executing client software 212 generates a digital asset. The clientsoftware 212 intercepts a create or a save command for the digital assetand generates (step 510) an asset identification tag. The assetidentification tag is the meta-data that is associated with the digitalasset. Further, the client software 212 associates (step 520) the assetidentification tag with the digital asset. The client stores (step 530)asset identification tag. Optionally, the asset identification tag istransmitted (step 540) to server 150 for storage in the centralrepository 336.

In one embodiment, generating an asset identification tag (step 510) isperformed when the digital asset is stored at the client. In anotherembodiment, the asset identification tag is created when the end-userbegins to create a new digital asset. For example, if the end-user of aclient creates a new folder or directory for storing digital assets, theclient software 212 examines any rules that related to the creation ofthe folder to categorize the new folder based first on the device onwhich the folder is being created, next based on the applicationcreating the folder, and lastly the end-user creating the folder.However, if required, the end-user can be prompted to providecategorization information via an end-user interface. The categorizationdata is saved and the folder is created within the file system of thedevice. It should be understood that once a categorization data isapplied to a digital asset, the categorization may be changed at a latertime, if the associated rules allow. This allows for recategorization ofcertain digital assets while preventing recategorization of otherdigital assets. The terms rule and policy are used interchangeablythroughout the specification.

In various embodiments, application rules define the set of categorizeddigital assets (e.g., taxonomy tags) that can be stored with a directoryor file when that directory or file is created by an application.Application rules consider the name and context of the digital asset(binary name, binary versions, process name, window titles, and thelink) and the name of the directory being created. From this data a setof taxonomy tags are determined and returned as the list of is tags forthis digital asset.

Device rules define the set of taxonomy tags that can be applied to adirectory or file when that directory or file is created by or stored ona particular device. Rules can be defined for device classes (e.g.,local fixed device, network device, removable devices), individualstorage devices or input devices. Similarly, end-user rules define theset of taxonomy tags that can be associated with a directory or filewhen that directory or file is created or changed by the end-user. Userrules can consider the end-user's name, the end-user's role, theend-user's location or any other data that can be retrieved from a localor directory based end-user configuration.

By applying rules and categorizations to folders, directories,end-users, and devices, automatic and inheritance based categorizationof digital assets is achieved. For example, if a word document is storedin a specific directory, the client software 212 applies the taxonomytag indicated by the rules and categorization of the directory thatstores the word document. Further, if a one or more uncategorizeddigital assets are moved into a categorized directory those digitalasset inherent the categorization of the directory. Such a featureallows for the categorization of digital assets existing on the client110 prior to the installation of the client software 212.

The following example is designed to illustrate one embodiment ofcategorizing a digital asset. The example should not be read to limitthe scope the invention. Assume that an end-user John Smith who worksthe finance department creates an Excel file in the“\\finance\john\budget” folder of his home directory that wascategorized using the taxonomy tags 430 and 440. The client software 212creates meta-data that contains various categorization information basedon John's identify such as: data created, author, department, etc. Theclient software 212 can also add meta-data resulting from the rulesassociated with the “budget” folder (or its parent folder Finance) suchas confidential, marked for compliance, do not delete, do not email, andthe like. The level of meta-data granularity can be further augmentedwith input from John using the graphical user interface if desired byJohn or required by the rules.

A method 600 of providing meta-data information using the graphical userinterface is shown and described with reference to FIG. 6. The clientsoftware 212 provides (step 610) the end-user of the client 110 with agraphical display having one or more dialog boxes, lists, or radiobuttons. The end-user manipulates the graphical user interface toprovide meta-data that is associated (step 620) with the digital asset.Manipulation can include, but is not limited to, selecting a taxonomytag 430 to apply to the digital and the like.

In addition to generating categorization information as part of themeta-data for a digital asset, the client software 212 can generate adigital identifier for each digital asset. One embodiment of a method700 for generating such a digital identifier is shown and described withreference to FIG. 7. For example, during a save operation the clientsoftware 212 analyzes (step 710) the contents of the digital asset usinga hash function. In one embodiment, the client software 212 analyzes thetext of the digital asset. In other embodiment, additional or otherelements of the digital asset are analyzed. For example, thecategorization information can also be included in the analysis, or inthe case of an email or instant message the sender and recipient of theemail or instant message. Examples of hash function that can be used bythe client software 212 include but are not limited to MD5 (IETFRFC1321) and SHA1 (IETF RFC3174).

Also, the meta-data can include a list of keywords that are a part ofthe digital asset. One method of generating the list of keywords for thedigital asset is to analyze the digital asset and record words ofimportance. It should be understood that certain words will not berecognized as keywords. For examples, articles such “a”, “an”, and“the”, or pronouns, will not be recorded as keywords. Various knowntechniques can be used to generate the list of keywords for the digitalasset.

The combination of the digital identifier, keywords, and thecategorization information described above, or respective combinationsof portions of each create the asset identification tag (i.e.,meta-data) for the digital asset. As previously stated, the assetidentification tag is associated (step 520) with the digital asset.Association can include creating a “hidden” file that stores themeta-data that is permanently linked to the digital asset. As usedherein, permanently linked refers to an association that can not beremoved regardless of the transmission, moving, or copying of thedigital asset. For example, if a digital asset is emailed to anotherend-user the associated asset identification tag is emailed as well. Thepropagation of an asset identification tag will be described in moredetail below.

In one embodiment, storing (step 530) the asset identification tagincludes storing the asset identification tag in the persistent storage216 of the client 216. The asset identification tag can be stored in thesame shared storage area as the digital asset. Alternatively, the assetidentification tag is stored separate from the digital asset. Forexample, in a different dedicated memory location or another storagedevice.

In order to determine whether to transmit (step 530) a copy of the assetidentification to the server 150, the meta-data of the digital asset isresolved to one of three levels: (1) unmanaged; (2) managed; or (3)records managed. In one embodiment, if the digital asset is resolved tobe unmanaged then the asset identification tag is not stored by theclient 110 or the server 150. However, if the asset identification tagis resolved to be managed then the asset identification tag is storedlocally at the client 110. Finally, if the asset identification tag isresolved as records managed a copy of the asset identification tag istransmitted to the server 150 to notify the server software 312 of theexistence of the digital asset. It should be noted that actually thedigital asset is not transmitted to the server 150, but instead thedigital asset is stored locally at the client 110. Although described ashaving three levels of resolution, it should be understood that a fewernumber or greater number of levels are possible.

The advantages of having a class of “managed” digital assets and a classof “records managed” digital asset is to treat the digital assets in themanner similar to the other assets of a corporations. For example, lookat the difference between pencils and computers in a corporation. Aswith any asset in a corporation, pencils need to be managed. In the caseof pencils, the corporation likes to know how many have been ordered andhave a general idea of when to order additional pencils. The corporationis typically not concerned with who has a pencil or how many pencils areowned by each person. In contrast to pencils, the corporation wants toknow exactly which end-user has each computer and where the computer islocated. This analogy translates directly to digital asset. For example,“managed” digital asset can be mapped to pencils and “records managed”digital assets can be mapped to computers. An example of a manageddigital asset can be a voice mail from potential new client. An exampleof a records managed digital asset can be an invention disclosure. Byusing a leveled approach to digital asset classification, thecentralized repository needs only to track a percentage of the digitalassets in the distributed computing environment 100 instead of all thedigital assets. The digital assets that are not tracked by thecentralized repository are tracked by the clients 110. As previouslyexplained, the clients 110 track each of the assets that are storedlocally a the client.

One way to determine which digital assets are unmanaged, managed, orrecords managed is to use the taxonomy tags 430. As previously stated,each digital asset is associated with at least one tag 430 of thetaxonomy 400. The taxonomy tag includes policy information (e.g., rules)and a digital asset classification level. Other meta-data entries canalso be used to determine whether a digital asset is unmanaged, managed,or records managed. For example, the creation date of the digital assetcan be used.

In one embodiment, any digital asset that exists on a client 110 whenthe client software 212 is installed is automatically categorized asunmanaged. As a result, no meta-data entry on the client is created forthese digital assets. The taxonomy 400 can include a tag 430 in it thatis labeled “unmanaged” that includes associated policies that areapplied to unmanaged digital assets. Typically a small set of policiesis used. For example, an expiration date (i.e., expire the asset in 1year) and also a location control policy that does not allow the digitalto be moved, copied, emailed, or otherwise transferred from the currentclient 110. Similarly, every other tag 430 of the taxonomy 400 caninclude a rule that creates a meta-data entry giving the digital asset alevel of either managed or records managed. For example, if a digitalasset is associated with the IP tag 430 the meta-data for the digitalasset indicates that the digital asset is classified as managed.Further, if the digital asset is associated with the disclosure sub-tag440 the meta-data for the digital asset indicates that the digital assetis records managed and a copy of the meta-data is transferred to theserver 150 for storage.

In addition to a digital identifier and categorization information, themeta-data for a digital asset can include a list of operations performedon the digital asset by the client 110. This information can be thoughtof as an audit history and is useful for many things. For example,determining the number of copies of a digital asset that exists, whichend-user created the copies, what application created the copies, whatis the source of the copy of the digital asset, and which devices storedthe copies. The resulting copy not only includes all the contents of theoriginal digital asset, but also the meta-data for the original digitalasset, which include the digital identifier of the original file. Saidanother way, when a copy operation is performed both the contents of thedigital asset and its associated meta-data are copied.

It should be understood that the audit information for the same digitalasset existing on the different clients 110 can have different contents.If the digital asset is records managed, the audit information for eachasset is transferred to the server 150 as part of the meta-data for theasset. The server software 312 performs a union of the auditinformation, propagates the unionized audit information to the clients110, and instructions the client software 212 to remove the local copyof the pre-unionized meta-data and replace the pre-unionized meta-datawith the unionized meta-data.

Various methods for copying various digital assets are known. Methodsfor files and email, both of which digital assets, are described below.The most straight forward way to create a copy of a digital asset is toprint the digital asset onto paper. This creates a “hard copy” of thedigital asset. It is important to track the printing of digital assetsfor a number of reasons. One reasons is for expiration purposes. It isdesirable to know that if a digital asset was printed the day of itsexpiration that the paper copy was also destroyed. Another reason fortracking copies of digital assets, is to monitor which end-users areaccess and copying which digital assets.

Also, there are many different ways that an electronic copy of a filecan be created by the end-user of the client 110. For example, theend-user can execute the “copy” command in windows explorer and thenexecute a “paste” command in another location. This causes a copy of thecontent of the file to be created. Even though there are many methods tocreate a copy of a file, the actual create of the new copy must gothrough the file system of the client 110. As a result, filter driver254 is used to identify when a new file for the file system is created.

It is also important to determine when an open file of the file systemis written to. For example, an application might open a first file “A”for reading and a second file “B” for writing. The application under theinstruction of the end-user copies the contents of the first file A tothe second file B. In this example, the second file B was not created itwas only updated with the contents of the first file A. In anotherembodiment, file B is created as a new file and the contents of file Aare copied into file B.

Similar to files, there exists a number of methods that can be employedto create a copy of an email. The simplest method is to “copy” an emailand then “paste” it using the functionality provided by the emailapplication of the client 110.

Another way to create a copy of an email is to copy the folder or theemail application file that stores the email or emails for the emailapplication. Within an email application, an email can be stored withina “folder” of the email application to provide a means to organize theend-user's email. The folders and emails that are displayed to theend-user of the email application are stored in files or directories ofthe client 110, which may be file system folder. Using MICROSOFT OFFICEOUTLOOK as an example, the application creates and uses the .OST and.PST files for holding the definitions of the folders and the emailsshown to the end-user of the application. One method the end-user canuse to create a copy of email is to export the email out of the emailapplication. Outlook provides an interface that allows one to exportinformation. Using this feature, one can put the email into a text file,excel spreadsheet or even a .PST file thereby creating a copy of theemail.

Another method of creating a copy of email is to simply copy the OSTand/or the .PST file outside of the email application. In this case, theemail application is not necessarily executing on the client 110 duringthe copy operations. This operation is similar to the copying of a filefrom the file system as described above.

With respect to FIG. 8, a method 800 of tracking a copy of a digitalasset in the distributed computing environment is shown and described.In one embodiment, the method includes determining (step 810) if a copyof the digital asset is created, generating (step 820) a meta-data entryfor the original digital asset that indicates a copy was made, andupdating (step 830) the stored meta-data for the digital asset.

The determining (step 810) can be accomplished in many ways. In oneembodiment, the meta-data of the digital asset being created is comparedto a list of know meta-data stored on the client 110 or server 150. Inanother embodiment, only a portion of the meta-data is used to do thecomparison (e.g., the digital identifier).

In another embodiment, the filter driver 254 or the plug-in 258 monitorsthe action of the applications executing on the client with respect tofile I/O. By monitoring an application and its threads, the clientsoftware 212 can determine what files are being opened for reading andwhat files are being open for writing. For example, if an applicationhas opened file A and file B for input and file C for output. File Cinherits, as previously described, all the meta-data (e.g., controlpolicies and the like) from both file A and file B and associates themwith file C. This method addresses the case of either creating file C asa new file or opening an existing file C for write. Once the first I/Ois completed to the output, the meta-data will be updated to the unionof file A and file B as described in more detail below. Further, if fileC is stored in a folder having an applied taxonomy tag 430, resultingmeta-data is the union of file A, file B, and the folder.

The generation (step 820) of meta-data can be accomplished in variousways. For example, when a print (from the perspective of the clientsoftware 212 is essentially creating a paper copy of the digital asset)is executed meta-data about the print is add to the meta-data of theprinted digital asset. This meta-data can include various combinationsof the date and time the digital asset was printed, which end-userprinted the digital asset, which digital assets were the source of theprinted digital asset, the digital identifier from the source digitalassets, and what printer generated the paper copy of the digital asset.

Also, various methods of updating (step 830) the meta-data for thedigital asset can be used. For example, in the case of a managed digitalasset the meta-data previously stored about the digital asset isrefreshed with the copy meta-data. In the case of a records manageddigital asset, after the locally stored meta-data is updated the updatedmeta-data is transmitted to the server 150 for storage.

In certain instances, it is desirable to suspend the creation ofmeta-data for a digital asset. For example, during the installation ofother software applications. Typically, when installing software, aprogram is executing commands that will cause folders to be created. Theend-user could be bombarded with requests for categorization of folders.Because of this, there is a special command that can be executed by theend-user of the client 110 that informs the client software 212 tosuspend its operation. After the installation of the software, theclient software 212 resumes it's normal operation. Although theoperation of the client software 212 can be suspended, the inventionmonitors what operations are performed while the client software 212 issuspend and records this information to a general audit log for theclient 110.

After creating meta-data for each of the digital assets, the meta-datacan be used to provide various features of the invention. Some of thesefeatures are provided by the client software 212, some are provided bythe server software 312, and some are provided by the cooperation of theclient software 212 and server software 312.

One feature provided by the client software 212 is the ability to locatea digital asset using the keywords and meta-data associated with thedigital asset. As used herein, the term locate is used synonymously withthe term search. Because each client 110 stores their digital assetslocally, the possible solution set to a locate request is a closed setof digital assets. In essence, when a locate command is executed thefull set of possible keywords and meta-data tags that could be used inlocate are shown to the end-user of the client 110 as a set ofvirtualized folders. This removes the requirement from the end-user toinput a search term in a search engine if the end-user can not think ofa search term. Because most end-users work in a focused area, the numberof taxonomy tags and the number of unique keywords stored in themeta-data of the digital assets words are typically limited to theend-users focused work area.

With reference to FIG. 9, a method of locating a digital asset in thedistributed computing environment 100. In one embodiment, the methodincludes receiving (step 910) a search command from the end-user of theclient, identifying (step 920) the taxonomy tags 430 associated with thedigital assets that are stored locally at the client, and displaying(step 930) one or more folders to the end-user of the client 110. Thefolders include labels that are the identified taxonomy tags 430.

Receiving (step 910) a search or locate command from the end-user of aclient 110 can be accomplished in various ways. For example, theend-user can select a hot key (e.g., F12) on a keyword. In anotherembodiment, the end-user can select a portion of a digital asset andright-click on the selected portion. As a result, a menu is displayed tothe end-user that includes a locate menu item. Additionally, theend-user can select a search command from a start menu option.

Various means of identifying (step 920) the taxonomy tags 430 associatedwith the digital assets of the client 110 are contemplated. In oneembodiment, a scan is performed of all the digital assets stored at theclient 110 to determine which taxonomy tags 430 are associated with thedigital assets. In another embodiment, the end-user can supply a searchterm to the locate function. As a result, the identified digital assetsinclude the provided term in their associated meta-data. Alternatively,the provided term is used to exclude taxonomy tags 430. In addition toidentifying taxonomy tags 430, the client software 212 can identify thekeywords in the associated meta-data for the digital assets. Also, acombination of taxonomy tags 430 and keywords can be used.

Once the taxonomy tags 430 and/or keywords are identifies, the clientsoftware 212 generates a virtualized file system view of the associateddigital assets and displays (step 930) to the end-user. In oneembodiment, the familiar graphical “explorer” interface is shown to theend-user. With reference to FIG. 10, the explorer view 1000 depicts oneor more folders 1004 and/or files to the end-user. The virtual folders1004 include a label that is one of the identified taxonomy tags 403 orkeywords. The virtual folders 1004 are not the actual file systemfolders. Creation of the virtual folders is accomplished by the clientsoftware 212.

Selecting one of the virtual folders 1004 results in another display ofanother set of virtual folders. In essence, the system provides a meansto “drill down” into meta-data of the digital assets to locate a desireddigital asset. By selecting a displayed virtual folder, the clientsoftware 212 is in essence performing another search using only the setof digital assets selected from the first search.

Another feature enabled by the meta-data and client software 212 of thepresent invention is the ability to control and maintain a documentexpiration policy. By using the associated expiration date that ispresent in the meta-data for the digital asset, different sets ofdigital assets can be exposed to an archive system and recorded toseparate mediums. For example, all digital assets and only the digitalassets having an expiration date in the range of a given week areexposed to the archive system. At the end of that indicated week, thearchive tape can be destroyed, thereby destroying the backed-up copiesof the digital assets.

One embodiment of a method 1100 of expiring stored digital assets isshown and described with reference to FIG. 11. The method includesproviding (step 1110) a date range using the client software 212,enumerating (step 1120) the digital assets that have an expiration datewithin the provide range as file system elements, and storing (step1130) the enumerate assets on a storage medium.

The end-user provides (step 1100) a date range to the client software212 using a graphical user interface or a command line entry. In anotherembodiment, the client 110 includes one or more archive scripts that areexecuted automatically. The scripts include date ranges used to exposespecific digital assets to the archive system. Although described asstoring the digital assets having the associated date range, it shouldbe understood that the provided data range can indicate digital assetsthat are not be exposed. An indicator or flag (e.g., an exclamationpoint) can be used to indicate the described “not” function. Alsocombinations of both types of date ranges can be used to generate thedesired set of digital assets. In addition, the meta-data associatedwith the digital assets can be used to define the set of digital assetsthat are exposed for archiving.

Using the provided data range, the digital assets are separated using avirtual file system. In one embodiment, the filter driver 254 creates avirtual file system enumerating (step 1120) those digital assets havingan expiration date within the provided date range. Conceptually, thevirtual file system acts as a mask over the actual file system of theclient. The mask exposes only those digital assets fulfilling theindicated criteria to the archive system.

The exposed digital assets are copied (step 1130) to a storage medium.The storage medium can be a tape, disk, or other suitable storagemedium. In one embodiment, the digital assets that are copied to thestorage medium are encrypted prior to be copied to the storage medium.In another embodiment, when an expiration date is assigned to themeta-data of the digital asset the digital asset is encrypted (step1140) when the digital asset is stored in the file system of the client110. Digital assets having similar expiration dates can each beencrypted with the same encryption key, which can also be stored on thestorage medium or separate from the storage medium. The encryption keyis assigned an expiration date. After the expiration of that date, theencryption key is destroyed (step 1150). In another embodiment, aseparate encryption key is used to encrypt each digital asset.

There are many methods that can be used encrypted the digital assets.For example, an application can encrypt the digital assets.Alternatively, each client can have an encrypted file system such as theMicrosoft Encrypted File System. In another embodiment, the filterdriver 254 or plug-in 258 can perform the encryption

Another feature enabled by the meta-data and client software 212 of thepresent invention and in some embodiments the server software 312 is theprevention of the restoration of a previously expired digital asset. Inone embodiment, once a digital asset has been expired the actual digitalasset is removed from the client 110. However, the meta-data remains atthe client 110 and in the case of a record managed digital asset at theserver 150. The meta-data can include an entry that the digital assethas been previously expired.

With reference to FIG. 12, a method 1200 for prevention of restorationof a digital asset is shown and described. In one embodiment, the methodincludes receiving (step 1210) meta-data associated with a digital assetthat was previously created by a client 110, comparing (step 1220) thereceived meta-data with the stored meta-data on the client 110 and/orthe server 150, and preventing (step 1230) the restoration of thedigital asset when the received meta-data matches stored meta-data forthe digital asset that indicates the digital asset was previouslyexpired.

As previously explained, the client 110 and the server 150 need not bein constant communication because the digital assets are not stored atthe server 150, and further a full copy of the meta-data is stored atthe client 110. When a digital asset is restored to a client 110 thatdid not create the digital asset and thus does not have a meta-dataentry to compare the restored asset to, the client 110 establishes aconnection to the server 150. Once the connection is established, theclient 110 transmits the meta-data to the server 150 where it iscompared (step 1220) against the meta-stored stored at the server 150.

In one embodiment, the comparing step (1220) includes comparing theentire meta-data contents with the list of known meta-data. In anotherembodiment, a portion of the meta-data is compared to the list of knownmeta-data. The portion of the meta-data can include, but is not limitedto, the digital identifier or a taxonomy tag. During the comparisonprocess, the client 110 can disconnect from the server 150 or maintainthe communication link 120 with the server 150.

When the server 150 finds a match between the restored digital assetmeta-data and previously expired digital asset meta-data, the server 150issues a command to prevent (step 1230) the restoration of the digitalasset to the client 110. In one embodiment, the command includesinstructions to remove the restore digital asset. In another embodiment,the command includes instruction to not allow the digital asset to becopied to the file system of the client 110.

Another function provided by the client software 212 of the presentinvention is the ability to control access to digital assets using theassociated meta-data of the digital assets. Using the meta-data that isassociated with each digital asset, role based, user based, and acombination of role based and user based access is provided.

One embodiment of a method of providing meta-data based access to adigital asset is shown and described with reference to FIG. 13. Themethod includes receiving (step 1310) a request to access the digitalasset, determining (step 1320) a categorization of the digital asset,evaluating (step 1330) any rules associated with the categorization, andallowing (step 1340) access to the digital asset when the determiningand evaluating indicate access is allowed.

In one embodiment, the receiving (step 1310) includes intercepting, bythe filter driver 254 or plug-in 258, a file system access request. Thefile system access request can include, but is not limited to, a copyrequest, an open request, a move request, a delete request, and thelike.

The filter driver 254 or plug-in 258 analyzes the meta-data associatedwith the digital asset. The analysis includes, processing the meta-datato determine (step 1320) which taxonomy tags 430 are associated with thedigital asset. The analysis also includes evaluating (step 1330) therules that are associated with the applied taxonomy tags 430. Forexample, if a digital asset was tagged as Finance/Budget, the associatedrules can be to restrict access to only all the executives and John, whois a consultant, when he is accessing the digital asset from a computerlocated at the offices of the corporation. The filter driver 254intercepts the file system request for access and ensures that that eachof the conditions is satisfied. If each of the conditions is satisfied,the requested access is allowed (step 1340). Although described from theperspective of the client 110, it should be understood the server 150can also perform the described method.

It is also desirable to prevent unauthorized access to digital assets bytrying to circumvent the rules and categorizations associated with thedigital assets. To that end, the invention propagates the meta-data withthe digital asset. For example, if a digital asset is attached to anemail the meta-data is also attached to the email. Similarly, if adigital asset is copied to a storage device, the meta-data associatedwith the digital asset is copied as well.

FIG. 14 depicts an embodiment of a method of propagating the meta-datawith a digital asset. The method includes generating (step 1410) ameta-data set for a digital asset, associating (step 1420) the meta-dataset with the digital asset, and transferring (step 1430) the meta-dataset with the digital asset.

The various methods of generating a meta-data set for a digital assethave been described above and will not be repeated here. The meta-dataset can have characteristics of the digital asset. For example, if thedigital asset is a word file, the meta-data set can have certainproperties of a word file as well. In one embodiment, the meta-data setis a hidden file.

The associated meta-data set is transferred (step 1430) with the digitalasset. Transferring can include, but is not limited to, copying,renaming, deleting, moving, emailing, and the like. In the case adigital asset is transferred as an attachment to an email, the meta-datacan be transferred using certain aspects of the email. It is known, whenan email is transmitted to a recipient the email format is defined bystandards from the IETF such as RFC 822 or the newer RFC 2822, theentire contents of which are herein incorporated by reference. Thesestandards provide for fields in the email header such as comments,keywords and an optional-field. The meta-data can be placed into thesefields using the plug-in 258 of the client software 212 or by a networkfilter driver 254 (not shown) that is located in the network driverstack of the client 110. By sending the meta-data with the digitalasset, the meta-data is received at the same time as the digital asset.

In certain instances, it is desirable to suspend the creation ofmeta-data for digital asset. For example, during the installation ofother software applications. Typically, when installing software, aprogram is executing commands that will cause folders to be created. Theend-user could be bombarded with requests for categorization forfolders. Because of this, there is a special command that can beexecuted by the end-user of the client 110 that informs the clientsoftware 212 to suspend its operation.

Referring back to FIG. 4, the adaptive feature of the adaptive taxonomyis described. One aspect of the invention is the ability of end-usersand administrators to create aliases 450 to taxonomy tags 430 to providean adaptive taxonomy 440. The aliases can be available only the end-userof the client 110 or available globally to all clients 110.Additionally, an alias can be promoted to taxonomy tag 440. Theinvention also provides a means to set a policy describing whichend-users can create aliases 450. As shown in FIG. 4, the alias 450labeled “INVENTION” refers to the taxonomy tag 440 labeled “DISCLOSURE.”Similarly, the alias 450 labeled “CV” is an alias for the taxonomy tag440 “RESUME.” Each alias inherits each of the rules and categorizationsof the taxonomy tag 440 to which it refers.

With reference to FIG. 15, a method of creating an alias for a taxonomytag is shown and described. The method includes creating (step 1510) adigital asset, presenting (step 1520) all or a portion of the taxonomytags 440 to the end-user, providing (step 1530) a graphical userinterface to the end-user if the end-user performs a specified action,and creating (step 1540) an alias using the graphical user interfacepresented to the end-user.

As previously explained the end-user can apply a presented taxonomy tagto a digital asset before the digital asset is saved to the file systemof the client 110 or after the digital asset is stored at the client110. The taxonomy tag 440 categorizes the digital asset and typicallyincludes at least one rule for the digital asset.

The end-user can specifically request the formation of an alias byperforming a specified action. The action can be, but is not limited to,selecting a button presented with the taxonomy tags 440 or not selectingone of the presented taxonomy tags. Once the client software 212determines that the end-user wants to create an alias 450, a graphicaluser interface is presented to the end-user that allows the end-user tocreate the alias 450. The end-user supplies a required set ofcharacteristics of the alias. For example, to which taxonomy tag 440 thealias 450 refers and an associated policy. The policy can be the samepolicy as the taxonomy tag 440 or a more restrictive policy.

The following example is designed to illustrate the adaptive taxonomyfeatures of the invention and is not intended to limit the invention.Referring to FIG. 4, the tag 430 labeled “Resume” that is used tocategorize resume information in the HR department. A policy isassociated with the Resume tag 440 that implements a first policy “A”.After policy A is in place and another end-user of the HR departmentdecides that the department needs a new tag called “CV”. The end-user ispresented with a graphical user interface that requires the end-user toprovide a taxonomy tag 440 to which the alias 450 CV is linked (i.e.,Resume), the reason for creating the alias 450, and whether a morerestrictive policy “B” should be applied to digital assets tagged withthe CV alias 450.

The alias 450 is able to be used by the end-user locally. However, itmay be desirable to allow other end-users to use the same alias 450. Tothe end, the alias 450 is transmitted to the server 150 for review by anadministrator.

As previously stated, the server software 312 provides certain featuresof the invention alone and in combination with the client software 212.Examples of features provided by the server software 312 include,promoting an alias 450 to a tag 430 and modifying the adaptive taxonomy400, performing unions of meta-data sets for digital assets, andlocating digital assets in the distributed computing environment. Eachof these features is discussed below in more detail.

An administration reviews the aliases that have been created by theend-users of the client 110 on a periodic basis. Continuing with theabove example, if the administrator agrees with the request to make analias 450 called “CV” the administrator modifies the taxonomy 400 toinclude the alias 450 CV using the server software 312. As previouslymentioned, the alias 450 can have the same policies as the Resumetaxonomy tag 440 or a more restrictive policy. The updated taxonomy 400is transferred to each client 110 the next time the client connects tothe server 150.

Alternatively, administrator can deny the alias 450 CV. As a result, thealias 450 CV is only available local to the end-user of the client 110that created the alias. Said another way, the alias 450 CV is notpublished to the other clients 110. The end-user can also remove localaliases as needed. As such, the digital asset is then tagged with thetaxonomy tag that the alias referred to prior to deletion.

Additionally, the administrator can “promote” an alias 450 to a taxonomytag 430. In essence, a promotion from an alias 450 to a taxonomy tag 430has the same effect as adding a new tag 430 to the adaptive taxonomy400. Continuing with the with above example, if it is later decided thata different policy should be applied to digital assets categorized as aCV versus those categorized as Resumes, the administrator can promotethe alias 450 labeled as CV to a taxonomy tag 430 and revise theassociated policy for the CV taxonomy tag 430.

It is conceivable that the same digital asset exists on multiple clients110. Each of the end-users can apply a different taxonomy tag 430 to thedigital asset. If the digital asset is a records managed asset, a copyof each of the meta-data sets associated with the digital asset arestored at the server 150. Having different policy information with thesame digital asset may allow for circumvention of the desired result ofthe present invention. To that end, a method of unionizing the meta-datasets for the digital asset is performed by, in one embodiment, theserver software 312.

One embodiment of a method 1600 of unionizing the associated meta-datatags is shown and described with reference to FIG. 16. The methodincludes receiving (step 1610) a first meta-data set for a digital assetfrom a first client 110, receiving (step 1620) a second meta-data setfor the same digital asset from a second client 110, and selecting (step1630) one of the categorizations of the digital asset of as the activecategorization. Although the other categorizations are present in themeta-data, only the active categorization and its associated policiesare enforced with respect to the digital asset.

Various methods are used to determine which categorization to select. Inone embodiment, the more restrictive categorization is selected. Forexample, the categorization that allows the fewest end-uses to accessthe digital asset is selected. Other examples include selecting thecategorization that allows the largest number of end-users access to thedigital asset, selecting the categorization that permits the fewestnumber of actions to be performed on the file, selecting thecategorization that allows the largest number of actions to be performedon the file, selecting the categorization having the earliestassociation date.

In one embodiment, the following method is used to determine whichcategorization to select. First a comparison between the retentionpolicies is performed and the categorization having the longer retentionpolicy is applied. If the retention polices are equal, then a comparisonof the expiration policies is performed. Again, the categorizationhaving the longer expiration policy is applied. If expiration policiesare equal, then the end-user is queried to provide a ranking to eachpolicy to resolve the conflict. In one embodiment, the inventionincludes a policy analysis engine that analyzes the policies when theyare created. In the case of competing polices, the end-user is queriedto rank the competing policies to the resolution of competing policy asapplied to the digital assets occurs automatically.

Each of the categorization remains with the meta-data set for thedigital asset. The not active categorization is not removed from themeta-data set. The reason for this is that different groups or end-userswithin an organization can view the value of a digital asset. Forexample, the legal department can view an offer letter as a contract,human resources can view the same offer letter as a salary benchmark,and manufacturing can view the offer letter as just a letter. Thisinformation is included as part of the audit information of themeta-data set. The below example illustrates certain aspects of theinvention.

Once the server software 312 identifies that the meta-data sets are forthe same digital asset the process of unionizing the meta-data set forthe digital asset is executed. For purposes of this example, assume thatan end-user of a first client categorized a digital asset “GeneralCorporate” and another end-user categorizes the same digital asset as“Budget”. Both categorizations are correct, but one is more correct. Theserver software 312 determines which categorization is stricter andselects that categorization as the active categorization.

The server 150 saves the information for each of the meta-data sets in amaster meta-data set for the digital asset. The master meta-data setincludes the information from each of the meta-data sets. The mastermeta-data set becomes the meta-data set for the digital asset and iscommunicated to each client 110 the next time the client establishes aconnection with the server 150.

Although described with reference to the server 150, it should beunderstood that the client 110 is also capable of unionizing theassociated meta-files. The functionality is provided and used by theclient software 212. For example when a first file and a second file areeach copied and pasted into a third file, the client software 212performs a union of the first files meta-data the second files meta-datato generate a master meta-data set for the third file.

Another feature provided by the invention is the ability to located andfreeze the state of digital assets with in the distributed computingenvironment 100. In one embodiment, this feature is accomplished by thecooperation of the server software 312 and the client software 212. Onemethod of capturing a set of digital assets is shown and described withreference to FIG. 17.

In one embodiment, the method includes receiving (step 1710) by a client110 an instruction from the server 150 to copy specific digital assetsidentified by the meta-data for the digital asset, copying (step 1720)the identified digital assets, associating (step 1730) a respectiveaudit trail to each of the respective copied digital asset, andtransmitting (step 1740) the digital assets and their associated audittrails to the server 150.

To illustrate some of the features of the invention, the followingexample is provided. The example illustrates how an administrator ofserver 150 uses the software system of the invention to select a set ofdigital assets in the distributed computing environment 100 to be frozenand produced in litigation. The result of this operation is a report ofdigital assets of interest along with the locations of the information.

Each client 110 periodically checks with server 150 for issuedinstruction. If an instruction exists, the client 110 receives theinstructions. The periodicity can vary and can also be overridden. Forexample, the end-user of a client 110 can issue a connection request byperforming an operation using the client 110. In response to receivingthe instructions, the client software 212 analyzes the instructions andbegins their execution. In this example, assume the server 150 instructsthe client 110 to prevent modification (i.e., freeze) and generatecopies of indicated digital assets and their associated meta-data, whichincludes the audit history of the digital asset. After the serversoftware 212 copies a respective digital asset, that digital asset isreleased from the hold state so that the end-user of the client canaccess the digital asset. The client 110 transmits the copy of thedigital asset and meta-data to the server 150.

Each client 110 of the distributed computing environment 100 performsthe copy operating in parallel with the other clients 110. The serversoftware 312 includes functionality to provide a status reportdisplaying the number or percentage of clients 110 that received theinstruction, the number of clients 110 still to receive the instruction,and the number of clients 110 that have completed the copy andtransmission operations. It should be understood other progress metricscan be included in the reporting functionality of the invention.

The previously described embodiments may be implemented as a method,apparatus or article of manufacture using programming and/or engineeringtechniques to produce software, firmware, hardware, or any combinationthereof. The term “article of manufacture” as used herein is intended toencompass code or logic accessible from and embedded in one or morecomputer-readable devices, firmware, programmable logic, memory devices(e.g., EEPROMs, ROMs, PROMs, RAMs, SRAMs, etc.), hardware (e.g.,integrated circuit chip, Field Programmable Gate Array (FPGA),Application Specific Integrated Circuit (ASIC), etc.), electronicdevices, a computer readable non-volatile storage unit (e.g., CD-ROM,floppy disk, hard disk drive, etc.), a file server providing access tothe programs via a network transmission line, wireless transmissionmedia, signals propagating through space, radio waves, infrared signals,etc. The article of manufacture includes hardware logic as well assoftware or programmable code embedded in a computer readable mediumthat is executed by a processor. Of course, those skilled in the artwill recognize that many modifications may be made to this configurationwithout departing from the scope of the present invention.

While the invention has been shown and described with reference tospecific preferred embodiments, it should be understood by those skilledin the art that various changes in form and detail may be made thereinwithout departing from the spirit and scope of the invention as definedby the following claims.

1. A method of providing access to a digital asset of a distributedcomputing environment, the environment having a central computing devicethat stores an asset identification tag for at least one digital assetand one or more clients that locally stores respective digital assets,the method comprising: (a) receiving a request from a user for access toa digital asset; (b) determining a categorization associated with thedigital asset; (c) evaluating a rule associated with the categorizationof the digital asset to generate a result; and (d) providing access tothe digital asset when the result indicates that the end-user is allowedto access the digital asset.
 2. The method of claim 1 wherein at leastone of steps (a), (b), and (c) is performed at the client.
 3. The methodof claim 1 wherein at least one of steps (a), (b) and (c) is performedby the central computing device.
 4. The method of claim 1 furthercomprising receiving, at a client, the rule associated with thecategorization from the central computing device.
 5. The method of claim1 wherein step (a) is performed by a filter driver.
 6. The method ofclaim 1 wherein providing access comprises performing an operation onthe digital asset selected from the group consisting of: reading,writing, deleting, copying, moving, transmitting, transferring, andrenaming.
 7. A system for providing access to digital assets of adistributed computing environment, the environment having a centralcomputing device that stores an asset identification tag for at leastone digital asset and one or more clients that locally stores respectivedigital assets, the system comprising: a computing device that receivesa request from a user for access to digital assets, determines acategorization associated with the digital asset, evaluates a ruleassociated with the categorization of the digital asset to generate aresult, and provide access to the digital asset when the resultindicates that the end-user is allowed to access the digital asset. 8.The system of claim 7 wherein the computing device is the client of thedistributed computing environment.
 9. The system of claim 7 wherein thecomputing device is the server of the distributed computing environment.10. The system of claim 7 wherein the server of the distributedcomputing environment transmits the rule associated with thecategorization to the computing device.
 11. The system of claim 7wherein the computing device comprises a filter driver.
 12. The systemof claim 7 wherein the computing device provides access by performing anoperation on the digital asset selected from the group consisting of:reading, writing, deleting, copying, moving, transmitting, transferring,and renaming
 13. A computer readable medium having executableinstructions thereon to provide access to a digital asset of adistributed computing environment, the environment having a centralcomputing device that stores an asset identification tag for at leastone digital asset and one or more clients that locally stores respectivedigital assets, the computer readable medium comprising: (a)instructions to receive a request from a user for access to a digitalasset; (b) instructions to determine a categorization associated withthe digital asset; (c) instructions to evaluate a rule associated withthe categorization of the digital asset to generate a result; and (d)instructions to provide access to the digital asset when the resultindicates that the end-user is allowed to access the digital asset. 14.The computer readable medium of claim 13 wherein the execution of steps(a), (b), and (c) is performed at a client of the distributed computingenvironment.
 15. The computer readable medium of claim 13 wherein theexecution of steps (a), (b), and (c) is performed at the server of thedistributed computing environment.
 16. The computer readable medium ofclaim 13 further comprising instructions to receive, at a client of thedistributed computing environment, the rule associated with thecategorization from the central computing device.
 17. The computerreadable medium of claim 13 wherein the instructions to receive arequest is performed by a filter driver.
 18. The computer readablemedium of claim 13 wherein the instructions to provide access comprisesinstructions to perform an operation on the digital asset selected fromthe group consisting of: reading, writing, deleting, copying, moving,transmitting, transferring, and renaming.